=================================================
== titanium-info.txt==

Notes sur l'AMS 3.00 de la TI-89 Titanium
- Olivier Armand - ola dot e-ml at wanadoo dot fr

Cration : 8 juin 2004
Dernire maj : 30 juin 2004

* Ne pas redistribuer * Do not redistribute *
=================================================


Toutes les adresses sont comptes avec ROM_BASE  $200000 au lieu de
$800000 pour plus de facilit.

========
Adresses
========

ROM de 0  0x156eb2 inclu -> Comme si allait de 0x212000  0x368eB2
inclus.
Le boot de la Titanium est  0x800000. Les certificats sont 
0x810000, etc...

=======================================================
Patches effectus pour obtenir titanic_patched_orig.rom
=======================================================

titanic_patched_orig.rom pourra ensuite passer par le patcheur
automatique patchanic.

- La ROM fait 2Mo : une partie de la mmoire rserve aux Flash Apps /
  archives est coupe dans l'image de Samuel (et on lui enlve un
  octet)

- VTI regarde  Boot+5 pour avoir le type de calc (89 ou 92+). Patcher
en 0x20.b pour qu'il mule une 92+.

- 0x210000 (0x10000) mis  0xFFF8 pour viter d'avoir un Corrupt
  Certificate Memory au boot. 0x210002.w est mis  0 pour passer 
  l'AMS en cas de reset (voir la partie BOOT plus loin). Pour excuter
  le boot sans passer par l'AMS, mettre quelque chose diffrent de 0
  (mais attention, les nouveaux ports i/o le feront boucler
  indfiniment dans l'appel  20041A [qui lance le code principal du
  boot. Semble ne pas y voir de problme si on boot avec vecteur
  $200100 et d0.l != 0 ??? (param du boot)]
  Maj : des fois se lance, des fois non... Ou simplement un ini de
  ports pose problme avec l'cran ?).

- Fonction renvoyant la taille de la RAM renvoie maintenant 256ko (cf
  commentaire [1]). On patche cette fonction (move.w #$8AA,D0; trap #0)
  en remplaant les deux movea.l #$200000,a3 par #$40000,a3 (il
  testera ainsi un ghost existant vraiment).

[[[- Pour arriver aux routines cherchant les zones fin AMS/dbut
Apps/dbut Archives/fin Flash (patch similaire  celui pour la V200) :
 Au reset, dans la premire srie des bsr, on rentre dans le dernier 
 0x212488
 On rentre dans le jsr aprs le trap #A.
 On rentre dans la fonction 6 du trap #11, on arrive  0x24D418, c'est
 ici.]]]
=> Pas besoin de patch pour Titanium (lecture d'une variable pour
la fin de la flash sur Titanium, qui est correcte, cf [2])

[[[- Routine  0x24D6DC place juste aprs cette fonction du trap #11 qui
  a pour rle d'obtenir le dbut de la zone Archive (quivalent au
  filtre HW1 / V200) : il reste un filtre HW1 pour les 89 simples
  srement (mais ROM_BASE + $190000, ici $990000 (non patch par
  patchanic))
=> Xpand n'est plus ncessaire ! Et il n'y rien  patcher.

- Rom Call init_unit_system (303D3CC) : utilise une table d'adresses
  qui ne fait que 2 adresses... (spares par 4 octets). patchanic ne
  peut pas fonctionner, on  patche  la main. L'adresse de la table
  est place sur a2 quatre  instructions plus loin (c'est 30D2C8). 

- Suppression des Flash Apps de l'image de la ROM de Samuel qui
  semblent faire crire  $400000 (fonction 7 du trap #11 : nettoyage
  des apps).

- Une adresse absolue en mmoire au milieu de nul part :(  2DB766.

- Encore une table de 2 adresses, spares par 4 octets : 34514C.

[[[- Une table de 3 adresses non patches. patchanic ne peut pas se
  permettre de dtecter des tables de si petites tables, sinon
  n'importe quoi est patch. Corrig  la main : 306C8E (les adresses
  sont spares chacunes par 4 octets).
=> maj : patchanic est normalement maintenant capable de les detecter
  (il y en a plusieurs de ce type).

- Une table de 2 adresses spares par 4 octets, dcrivant les
  mthodes d'une Flash App interne (Self Test) : 2245A8.
  Les adresses des mthodes de toutes les Flash Apps internes sont ainsi
  patches  la main : on recherche "{S=" (magic number) et on patche
  les adresses qui se trouvent pas trs loin plus bas, juste avant le
  nom de l'App (sachant que pour la plupart, patchanic fera le
  travail).
 TODO Automatiser ceci, c'est faisable.

- Une adresse isole pour l'apps de configuration de l'horloge : 3535B2

[[- Des adresses isoles pour le Var-Link : 35693A, 356946, 356952, 356A1A
  35696A, 3569B0
=> maj : patchanic gre normalement ce patch automatiquement

- Le pointeur de la table des RC qui est un peu isol du reste :
  212150

- cmpi.w #$FFF8,ROM_BASE+$10000 du boot : la forme de l'instruction ne
  peut pas tre patche par patchanic. Il semble n'y avoir cette
  instruction qu'ici dans la ROM. 2008B0.

- Quelques adresses-variables dans la table des RC qui ne peuvent pas
  tre patches par patchanic (adresse trop leve) (ce patch n'est
  pas vraiment indispensable pour l'excution de l'AMS) : RC 43D
  (FlashMemoryEnd) et RC 43C (?HW1ArchiveMemoryBeginning) : 23D182 et
  23D186.

- Deux adresses isoles  DB778 spares de 4 octets.

- Deux adresses isoles dans le boot : $200100.

Pour detecter des patchs manquants : brktpt avec VTI sur
800000-A00000. Prendre la premire ligne (mme si la deuxime est
slectionne).


===================================
Commentaires sur la ROM (numrots)
===================================

*** !!!Ghost dangereux???!!! Eviter de l'utiliser.

[1] 2123e8: Pour effacer la RAM, au lieu d'avoir une adresse en dure comme
sur 89 ($3FFF4) pour la fin de la RAM, celle-ci est obtenue avec la
fonction $22224C [pas une RC] (puis -$C pour avoir l'quivalent de
$3FFF4).

ALGO:
Cette fonction prend une adresse sur la pile (ici NULL), la met dans
a1 et fait :
move.w #$8AA,D0; trap #0;
Le trap #0 dispatch la fonction :
regparm (a1) = res (pointeur)
if (res)
   *res = NULL;
Si les 1024 premiers octets de la RAM sont gaux  0x200000+x, 200000,
sinon 600000 -> a3.
*10000 = C5A3C5A3
....
-> teste si on peut relire ca aprs et boucle.
La boucle fait:
A0=10000
A2=0
D0=10000
Bcl:
Test (A0)
Si pas ok
   Si A2 = 0
   A2 = A0
Si ok
   Si A2 != 0
      Si res != NULL
	*res = A1
      Quitte
   Sinon
      D0+=10000
A0+=10000
Bcl tant que A0<A3

BUGS:
* Si trane continue de blocs invalides jusqu' la fin (A3),
*res = NULL
Pourquoi attendre un bloc valide pour crire le rsultat ?

RESUME:
long f(*long) : si param != NULL, y crit l'adresse du plus grand bloc
de 64ko de la RAM ne fonctionnant pas (ie adresse de fin de la RAM +
1), ou NULL si toute la RAM disponible (jusqu' 0x200000 ou 0x600000)
fonctionne. Si param = NULL, n'crit rien. Le premier bloc n'est pas test.
Retourne la quantit de RAM disponible, ou la quantit de RAM de
l'adresse 0 au premier bloc de RAM ne fonctionnant pas (non inclus).
La RAM va de 0  200000 (avec un reflet  400000), ou de 0  6000000
(vraiment ?) s'il n'y a pas de reflet.
Bizarre, surtout le fait d'attendre un bloc valide (un reflet par
exemple), cf BUGS...

APPELS:
au boot de l'AMS (2123e8) avec un paramtre NULL. Le rsultat (d0) est
stock dans une variable interne  l'AMS (5B2C). Cette variable est
utilise plusieurs fois, entre autres :
- pour calculer le checksum de la RAM par le trap #4
-  2DB46e, dans la fonction 2DB3C0, pour "Ram size" de la commande
getconfg(). Une petite fonction l'appel avec un paramtre NULL (2124e2).
Celle-ci est uniquement appele  251AD4, dans la fonction commenant
 25195e, dessinant la fentre Mem. Un appel  une fonction
quivalente xiste sur TI89, mais celle-ci retourne directement 0x40000.

Le boot semble utiliser 256ko de RAM uniquement (cf 0x2004A8)

VTI:
Retourne 0x200000  cause de l'mulation du ghost space (tous les
blocs semblent valides), et tout sera effac (et donc mme la table
des vecteurs !) -> patch.

HACK:
Faire retourner une valeur infrieure  la fonction semble tre
possible et ne pas gner ensuite l'AMS. Ceci permettrait de se reserver
de la RAM  la fin de celle-ci, qui ne sera jamais touche par l'AMS.
Il suffit de sauter de sauter aprs l'appel de la fonction, ou de
hooker le trap #0 si a aide.


---------------------------

*** !!!Attention  l'ancien FlashMemoryEnd qui ne sera plus valide.

[2] 0x21246C : appel au reset de la fonction  213028. La fonction
n'est pas une RC.
Elle appel la fonction $14 du trap #11 (nouvelle fonction).
Copie une fonction en RAM. Les commandes pour la FlashROM semblent
tre les mmes que celles pour la V200 (Sharp LH28F320BFHE-PBTLZ2), et
sont aussi compatibles avec les 89/92+.
Cf page 7 de la datasheet de la Flash de la V200.

ALGO: (en ROM  21303A)

lea CertMem,a1 ; Any valid address within the device (= the Flash
		 EEPROM chip)
               ; Sur TI, semble devoir tre CertMem absolument (?)
		 [mme chose sur V200]
move.w #$9090,(a1) ; Read Identifier Codes
move.w ROM_BASE,d1 ; Identifier code address + 0 -> Manufacturer Code
move.w ROM_BASE+2,d2 ; Bottom parameter device code
move.l #$400000,d0
cmp.w #$89,d1      ; Manufacturer Code (celui de la V200 est $B0)
beq Ret
cmp.w #$B5,d2      ;  Bottom parameter device code
beq Ret
move.l #$800000,d0
Ret:
move.w #$5050,(a1) ; Clear Status Register
move.w #$FFFF,(a1) ; Read Array
move.l d0,d1
addi.l #ROM_BASE,d1
move.l d1,a0
quit

Bottom parameter device (cf p.16 de la datasheet et shma p.6) : en
configuration bottom parameter pour le partitionnement, le plane de
paramtres est  l'adresse la plus basse de la puce.

Code fait : si FlashROM pas reconnue (ni manufacturer code, ni device
code), retourne ROM_BASE + ROM_BASE, sinon retourne ROM_BASE + 400000
(ce doit tre le cas sur les Titanium actuelles).

RESUME:
trap #11:$14 retourne dans a0 FlashMemoryEnd, et dans d0.l
FlashMemorySize, calculs dynamiquement en fonction de la puce.
Certains modles pourraient donc avoir 8Mo de Flash au lieu de 4Mo ?
Ou permet simplement d'tre compatible avec la TI89 (mais le fait que
ROM_BASE + ROM_BASE tombe bien comme il faut sur 92+ semble un peut
bizarre...)
Attention, la variable-ROM Call FlashMemoryEnd qui existait dj est
elle fixe : ROM_BASE + $400000.
d0 est stock au reset dans une variable interne ($5B1A). Il est aussi
shift  droite de 16 bits et stock dans $5B1E. Cette dernire
variable ne semble jamais utilise par l'AMS. Elle n'est accessible
via la table des RC.
a0 est stock la variable interne $5B28. Elle est retourne par la
nouvelle ROM Call (607) (voir commentaire [9]). La variable est
utilise un peu partout, notamment lors des critures en FlashROM.

APPELS:
appel au reset (c'est son seul appel, pour viter trop de dprotection
de flash inutile). La fonction n'est pas une RC.

VTI:
Renvoie une taille de $200000 et une FlashMemoryEnd  $400000, ce qui
convient. Pas besoin de patcher.

HACK:
Pourrait tre hack de la mme manire que le calcul dynamique de la
taille de la RAM, par un saut aprs l'appel ou en hookant le trap #11.
Un test rapide a t fait en faisant retourner a0 (FlashMemoryEnd) =
$380000 et d0 (FlashMemorySize) = $1800000 : getconfg() retourne une
taille de mmoire archive de 0, et le menu Mem un taille de 64ko (le
bloc pour la garbage collection) , ce qui est correct.


---------------------------

[3] Les Flash Apps risquent de commencer  $360000 au lieu de $340000 sur
TI89 AMS 3.00 si jamais il sort, tant donn sa taille (routine de
calcul des diffrentes zones : 24D476).

[4] Message affich  la prparation des Flash Apps (Installation in
progress... Do not interrupt!). (la barre charge  l'appel  $2DC434).

[5] Un test au reset fait afficher : USB: device not responding
Le Desktop est activ automatiquement comme sur V200.
Icne Window Editor du Desktop un peu modifie.
Quelques chanes ajoutes ou modifies :
-LINK TRANSMISSION ACTIVE: ON KEY ABORTS TRANSFER
+I/O ACTIVE: ON KEY ABORTS TRANSFER
-RECEIVED: 
+I/O: RECEIVED 
-SENDING: 
+I/O: SENDING 
-TI-89
+TI-89 Titanium
+USB: SENDING 
+VAR[,PORT]
+USB ACTIVE: ON KEY ABORTS TRANSFER
+USB: RECEIVED 
+USB: Searching for device
+USB: Device Not Supported
+USB: Device Not Responding
+ is archived!
+Are you sure?
Rception de donnes : affiche "I/O: RECEIVED main\data" pour le port
  non-USB (Avant, n'affichait rien).
Suppression d'une variable archive avec backspace depuis le Var-Link
  maintenant possible : affiche une bote de dialogue "main\data is
  archived! Are you sure?"

[6] "Installation in progress" et "Do not interrupt!" affichs  la
prparation des FlashApps ne sont pas sous forme de chanes dans l'AMS.
Est une image ?!

[7] Vti de JM ne permet plus de faire de Set program entry breakpoint. 

[8] Xpand ne semble plus ncessaire, cf les patches appliqus.

[9] Une partie des ROM Calls ajoutes avec l'AMS 2.07 n'existent plus
: readHandshake, writeHandshake, startBPTimer, stopBPTimer (auraient
pu tre utilises pour un protocole de communication). Un appel 
elles lance un ER_ROM_ROUTINE_NOT_AVAILABLE avec un dc.w $A36B (elles
pointent toutes vers ce dc.w).
La mme fonction que pour OSVRegisterTimer, OSVFreeTimer, qui
n'existent plus depuis AMS 2.04, est utilise (et ce sont peut-tre
les seules utilisations de la fonction et du message d'erreur).

*** !!! Ne plus utiliser l'ancienne ROM Call FlashMemoryEnd qui
    pourrait retourner un rsultat faux ?
[10] Apparition d'une seule nouvelle ROM Call : ROM_CALL_607.
Elle retourne dans a0 FlashMemoryEnd calcul dynamiquement par le code
du reset  l'aide de la fonction $14 du trap #11 (voir commentaire
[2]).

[11] Bhuvanesh : GetCalc/SendCalc have the port number as an optional
argument. If not specified or if it is zero, GetCalc will listen to
both ports, and SendCalc will use USB if there is a non-TI89 on USB,
otherwise it will use DBus.
AB_getGateArrayVersion() returns 3. I checked with Command Post Plus,
and hardwareRevision=2 and gateArray=3.
Et hardwareID = 9.

[12] Le mauvais fixage du masque de protection d'excution en RAM par
le trap #4 existe toujours (mauvaise adresse sur usp). Correction
ncessaire par hw3patch.
La seule diffrence dans trap #11:$F (calcul du masque de protection
d'excution en RAM) est un dblocage de 16 blocs de 4ko au lieu de 6.


---------------------------

========
trap #11
========

Dprotection :
- ori.b #1,$5B35 aprs le deuxime d0,(a0)
- Plus de bclr/bset  $600015. Ne sera pas compatible avec la HW1 ?
(pourtant le filtre HW1 de la mmoire archive existe encore, cf patches
appliqus). Le boot les a toujours par contre, lui. Le reset ne les a
plus.

A propos de $5B35
-----------------

Ceci est valable mme pour les anciennes versions d'AMS (pas regard
lesquelles exactement).

Au reset, aprs initialisation de quelques ports,  $212318 : test
$5B04.l pour un mot de passe ($F0A5960F). Si c'est le bon *ET*
(nouveau test spcifique  l'AMS 3.00) si $5B35 est nul (dtction
du trap #11 qui tait en cours d'excution) , excute un bout de code
situ prs de celui de l'AI6 ($22201C). Sinon test le mot de passe
invers (not) ($F5A69F0). Si c'est le bon, une routine du trap #4 qui
est appele ($221CCE), qui permet de rveiller la calc (le trap #4 est
repris en route, dtection d'un reboot pendant que la calc est teinte
par l'enlvement d'une pile, le boot permet de faire a, voir partie
BOOT). La valeur de a7 est rcupre d'une variable ($5B00).

L'AI6 teste aussi le mot de passe en regardant s'il correspond trap
#4 prcdemment ($F5A69F0). Sinon, il l'efface. Il lit un octet 
$5B30 (valeur du contraste) et le stocke. Puis il teste les piles
(3,4V). Si elles sont bonnes, il continue son excution normale
[222060] (teste la combinaison du reset et reset si besoin, et fixe la
valeur du constraste  celle dans la variable $5B30,  l'aide de la
sous-routine de OSContrastDn et Up [appel  2220B0] ).
Si les piles ne sont pas bonnes, efface le bit 2 de $600015, fixe la
waitstate ($600003)  $CD. Si le mot de passe n'est _pas_ $F5A69F0
(celui pour le trap #4), il met usp dans la pile et stocke a7 dans
$5B00 (mme variable que la lecture au reset), puis il crit comme mot
de passe $F0A5960F (permettra de revenir dans l'AI6 aprs
reboot). Puis dans les 2 cas, il attend un peu. Si le mot de passe est
$F5A69F0 (celui pour le trap #4), il finit l'AI6 en fixant le niveau du
contraste (cf plus haut). Sinon il efface le mot de passe, arme
$600015:2 (AI3), refixe la valeur de usp en la lisant de la pile (cf la
sauvegarde plus haut quand le mdp n'tait pas $F5A69F0), et fini l'AI6
en testant la combo de touches pour le reset et en fixant le contraste.

La routine de l'AI6 appele par le boot lors d'une dtection du mot de
passe $F0A5960F appelle une srie de fonction qui :
- Initialise plusieurs ports et variables (mme sous routine que le
  reset dans sa srie de bsr  $21249A, le 3me ici)
- OSLinkReset
- bsr  une sous-routine intialisant beaucoup de nouveaux ports et des
  variables srement lies  ces ports i/o. ($222026 -> 3479EA). Ce
  bsr n'est prsent que sur Titanium.
- Iinitalise des variables, et fait un OSRegisterTimer pour le timer 7.
- Initialise encore des variables avec la RC 473 (OSqclear, OSOnBreak,
  ...)
- OSRegisterTimer(APD)
- trap #11:$10 (mise--jour de la protection d'execution en mmoire
  archive)
- Appel le trap #11:$F (Changement du masque de protection d'excution
en RAM)  l'aide de la fonction $212D28, en lui donnant en paramtre
l'adresse permettant de dfinir la fentre d'excution (lue 
$5B0E). Il s'arrange avant l'appel pour mettre l'adresse  $14 + usp,
mais ceci est inutile ? Par contre le fait de fixer ssp = usp + $14
fait qu'aprs l'appel, usp + $10 pointe sur l'adresse de retour qui
est bien dans l'AMS, donc  trap #11:$F fera bien son boulot.

Puis il refixe la valeur de usp en la lisant de la pile (cf la
sauvegarde plus haut quand le mdp n'tait pas $F5A69F0), et fini l'AI6
en testant la combo de touches pour le reset et en fixant le
contraste. (mme fin que plus haut).

Le trap #4 met le mot de passe ($5B04)  $F5A69F0 avant d'avoir teint
la calc ($221C0E). Il le mettra  0 avant de quitter.

RESUME:
AI6 :
 Si mdp = $F5... (trap #4 en cours d'excution), et si les piles sont
 faibles, attend un peu, continue normalement. S'il y a des piles, ne
 teste pas la combinaison de touches de reset.
 Si mdp est autre chose, et si les piles sont faibles, stocke le
 contexte en RAM (ssp+usp), fixe le mdp  $F0... ('AI6 en cours'), et
 attend un peu. Puis efface le mdp, et continue normalement. 'AI6 en
 cours' ne correspond donc qu' cette boucle d'attente, et  des piles
 faibles.
trap #4 :
 Fixe le mdp  $F5... (trap #4 en cours) et l'efface  la
 fin.
reset :
 Si mdp est 'trap #4 en cours', saute  lui pour que la calc se
 rallume et qu'il finisse normalement.
 Si mdp est 'AI6 en cours', et sur AMS 3.00 si le trap #11 n'est pas
 'en cours' saute  lui pour qu'il rinitialise  plusieurs variables
 et ports i/o et finisse son excution  normalement.

TODO
A quoi sert l'AI6 ? trap #11 peut tre en cours ?
Contraste : remis si enlvement de pile sans avoir t teint
seulement. AI6 excut dans ce cas ?
Hook : si on appelle pas l'ancien AI6, la calc ne veut pas tre
allume (Manque acknowledge ?). Puis si on enlve une pile, se rallume
(et contraste pas bon).
Enlever une pile sans teindre sans l'AI6 d'origine provoque le reset
(d  h220xtsr apparamment).
Toute infos sur tout a est bienvenue.

HACK (non test):
Ralisable pour beaucoup d'AMS srement, et pour tous les modles.
Le systme de mot de passe permet d'excuter du code trs tt au
reset. Si on fait passer par l'AI6, la protection d'excution en RAM
est normalement rinitialise comme il faut (ghost space par
exemple). Le hook sera appel au rte (on place son adresse sur la
pile). Pour la Titanium, on peut avant de lancer le reset modifier la
variable interne $5B0E pour que l'excution du trap #11:$F par l'AI6
dbloque l'excution en RAM dans le bloc ou se trouve le TSR. Ou alors
on utilise un hw3patch.
Le code est appel seulement aprs une 20aine d'instruction du reset,
qui initialisent des ports i/o (tests des mdp  $212318).
Prendre garde  l'effacement complet de la RAM qui suit
encore plus loin.
Aucune ide si a a un quelconque intert.


$5B35 (suite)
-------------

Il est initialis  zro au reset, et entre autres par
EV_centralDispatcher et le rveil de la calc du trap #4.

Son bit 0 est arm au dbut du trap #11 et dsarm  la fin. Il
permet de dtecter que le trap #11 est en cours et viter une
rcupration du contexte par le code du reset.

Le bit 1 de $5B35 semble tre arm lorsque le port USB est actif (via
la commande TI-Basic sendcalc ou par l'envoi via le var-link). Aucune
ide pour la rception de donnes.
Quel est l'intert de ce bit, puisqu'il n'y a jamais de btst dessus ?

Les autres bits ne semblent pas tre utiliss.

---------------------------

trap #11 : $13
==============

Pas de fonction associe. Jamais utilis.
Ne fait qu'un rts !

trap #11 : $14
==============

Cf commentaire [2].

trap #11 : $15
==============
Fonction  212C8E
Param : d4.l, d5.w
Appels : 34E698, 3510C2
Code  24C4A6

(d3.l d6.w)
Affiche USB Active etc.
Lecture de certificats...
...
Semble utiliser toujours les mmes routines.
Msg Link transfer Complet ou link transmission error.

Appel  34E698 : gestion du link ? Un peu avant, une dialog demande si
overwrite ou skip.
Quelque chose  avoir avec les Flash Apps : entour de Ev_currentApp,
Ev_getAppID, OO_getAppAttr, OO_appMarkDelete (excut si oui  la
dialog), ROM CALL 424 qui appelle OO_DeleteMarkedApps (34E682),
FL_addCert, ...

Presque pareil pour le deuxime appel (autour se ressemble beaucoup !)
Pas le temps de regarder plus en dtail.

trap #11 : $16
==============

Fonction  212DC2
Param : void - Retourne : bool ?
Appels : 34B330
Code : 34B39E

Lecture de certificats, peut-tre de l'criture...
Pas le temps de regarder plus en dtail.


---------------------------

====
BOOT
====

Ce qui suit n'est pas spcifique  la Titanium.
Aprs plusieurs tests (pile, dprotection) et initialisation de ports
i/o, test  $200272 si (CertMem + 2).w est nul. Si oui, et si le
premier mot de l'AMS (ROM_BASE + $12000).w est non nul, l'adresse du
reset de l'AMS est cherche et l'AMS est boote. La RAM n'a pas t
modifie jusqu' maintenant, et en cas de pile enleve pendant un trap
#4, ceci peut tre rcupr (voir "A propos de $5B35" dans la partie
sur le trap #11.
Si un des deux tests choue, le boot continue son initialisation pour
arriver finalement  l'cran d'envoi d'AMS si tout s'est bien
pass. [le test des combo Apps+On et peut-tre '(-)' ')' + On doivent
se trouver srement avant ces 2 tests].
L'ancienne version de VTI remplace toujours CertMem par quelques
dizaines d'octets de certificat cod en dur de VTI, avec CertMem.w =
$FFF8 et CertMem+2.w nul -> le boot passe tout de suite la main 
l'AMS.
Dans la version de JM, les certificats sont ceux du .rom. Il est donc
ncessaire de patcher CertMem + 2 en le mettant  nul pour qu'un
'reset' de VTI lance tout de suite l'AMS.

Ce qui suit est spcifique  la Titanium.
Si on met quelque chose diffrent de nul, le boot bouclera un moment
dans le vide,  cause des nouveaux ports i/o que VTI ne fait pas
ragir correctement.

Le boot comporte maintenant quelques 'rts', plutt qu'un 4E75 cr
dynamiquement avant d'tre excut.

Les critures en RAM 'move.w a0,$4400' semes un peu partout dans le
code ont maintenant disparu du boot.


=========
Ports I/O
=========

Nouveaux  $7100XX, qui n'est maintenant plus un reflet de $7000xx.

ini par l'AI6
ini boot / reset
Routines  2051F4 - 347160 - 347640
sous-routines reset ?
Beaucoup d'utilisations dans le boot code :
Dans l'ordre d'apparition (adresses croissantes)
$81, $80, $4C, $39, $54, $31, $8B, $2F, $8F, $4D, $87, $29,
$5A, $5B, $4A, $4B, $55, $57, $56, $22, $24, $26, $8E, $89, $27,
$91, $94, $34, $A0, $2E, $96, $93, $9A, $9B, $95, $90, $98, $99, $92,
$97

Dans l'ordre (40 ports, tous en .b) :
$22, $24, $26, $27, $29, $2E, $2F, $31, $34, $39, $4A, $4B, $4C, $4D,
$54, $55, $56, $57, $5A, $5B, $80, $81, $87, $89, $8B, $8E, $8F, $90,
$91, $92, $93, $94, $95, $96, $97, $98, $99, $9A, $9B, $A0.

Avec les ports de l'horloge (cf plus loin) (prcds par #) :
$22, $24, $26, $27, $29, $2E, $2F, $31, $34, $39, #40.l, #44 #45,
#46.l, $4A, $4B, $4C, $4D, $54, $55, $56, $57, $5A, $5B, #5F, $80,
$81, $87, $89, $8B, $8E, $8F, $90, $91, $92, $93, $94, $95, $96, $97,
$98, $99, $9A, $9B, $A0.

Les ports qui suivent $A0 doivent aussi tre utiliss, mais jusqu'o ?
(cf 207136 ou $349212 (mme bout de code en plus peut-tre))

Trs proche des ports trouvs par Dan Englender pour la TI-84+ (cf
http://www.detachedsolutions.com/forum/viewtopic.php?t=1759). Serait
donc peut-tre le mme HW (voir commentaire plus loin).
J'ai crit  Dan, il n'a pas plus d'infos pour l'instant.

Les ports de Dan Englender manquant dans cette liste :
$49, $4F
Les ports que Dan ne cite pas : particulirement de $22  $39.

Les ports dans cette zone non cits ci-dessus ne semblent pas tre
utiliss (du moins pas par adressage directe, peut-tre que des (a0)+
sont utiliss, etc.).

-----------------------------

=======
Horloge
=======

[[ maj - rsum : l'horloge est maintenant entirement gre de faon
HW, afin de laisser l'auto-int3 libre pour l'USB.

[[Desktop : commentaires pour la dcouverte des ports, maintenant
inutile.
---------

AMS: un table  345164?
[[ maj : table contenant les adresses des nouveaux ports de l'horloge 

La premire adresse de la table ($71005F) est
lue par le Desktop  l'arrive de EV_NULL ($341EFC, premire
sous-fonction). Le bit 0 est test.[maj : IsClockOn!] S'il est non
nul, le reste de la table est utilis (345204, dans la sous-fonction
3451D2)
[maj] commentaire dplac dans OneSecondTimerGet plus bas.
A l'appel (341FC4) : _du32u32(d0.l=60, d1.l=f()) : -> f() / 60,
rsultat dans d1.l.
Si *($8324 + $BE) = d1.l -> quitte.
Sinon...
Au final, affichage de l'heure !

--- ---- --- --- -- --- --- ---- -- ---
Utilisation de la mme table pour toutes les fonctions de l'horloge.


IsClockOn
---------
Retourne $71005F:0

ClockOn
-------
bset $710005F:0
Si on avait avant le bset !IsClockOn, appelle
OneSecondTimerSet($5BB0 (ie OneSecondTimer), 0.w)
Dans tous les cas, $5BBE = 1. (indique ClockOn)

[Sur AMS 2.09 : Si pas HW1, bset 2,$600015; rts]

Ports relatifs  l'horloge :
$40.l (crire), $44, $45, $46.l, $5F:0

Toute cette gestion de l'horloge ne semble pas tre faite par le boot.

ClockOff
--------

Appel 3451D2 (getOneSecondTimer(pt_bidon))
Stocke le retour (d0) dans $5BB0. Puis bclr $5F:0 et clr.w $5BBE
(indique ClockOff).

AI3
---

N'est plus utilis pour l'horloge, mais pour le port USB (dclench 
son utilisation d'aprs le test que j'ai fait faire  Samuel). Utilise
des ports i/o de l'USB, et fait des TimerRestart (pas trop le temps de
regarder).
-> maintenant utilise comme interruption pour le traitement de
l'USB.
Le boot a maintenant tendance  avoir SR=$2200 plutt que $2300 
cause de a.

Trap #4
-------

clr.w $600014 avant d'teindre sur AMS 3, dans tous les cas (plus de
traitement avec l'AI3 comme sur la famille AMS 2.07).
Toute la gestion de l'AI3 qui rveille la calc a t supprime, et le
port $600014 est crit directement avec les valeurs plutt que d'avoir
les valeurs calcules en fonction de l'tat de l'horloge.

Seules diffrences apparentes : 2 nouvelles sous-routines appeles
tout  la fin (221D9E).
1re :
Si 5BBE.w && !IsClockOn
  $5BB0.l (OneSecondTimer ?) = 0
  ClockOn

2me :
Relatif au link USB srement.
wait $1DE84 *n cycles
Si $71004D:6 == 1
  Si $8410.b == $B0
    appel  une routine cmplexe utilisant $710039 (34781E)
    quitte
  sinon
    quitte
  Si $8410.b == $A0
   $8411.b = 2
quitte

Reset
-----

Routine de rinitialisation de l'horloge (23A3F2) (premire
utilisation des nouveaux ports).

Sur AMS 2.07 on avait :
<<Au reset, l'AMS vrifie si une variable interne (un long mot) proche
de la variable TimeFormat contient toujours un certain magic number
(0x2AAAAAAA). Si c'est le cas, alors l'AMS considre que la variable
DateFormat n'a pas t corrompue, et qu'il peut utiliser la valeur
qu'elle contient sans avoir besoin de l'initialiser.
Ceci permet  l'AMS de retrouver le format de date utilis avant le
reset, pour que l'utilisateur n'ait pas  re-rgler ce format.
Si le contenu de la variable de vrification ne correspond pas au
magic number, DateFormat est initialise  1. Si le contenu de la
variable de vrification ne correspond pas au magic number, TimeFormat
est initialise  12.>>

Sur HW3 (vu dans cette routine d'initialisation, avec la doc sur la
V200 / AMS 2.08) :
TimeFormat = 5BB6.b
DateFormat = 5BB7.b
TimeZone = 5BB4.w
5BBE.w ?
Magic pour la rcupration : 5BB8.l
OneSecondTimer = 5BB0.l (5C06 sur TI-89 AMS 2.09)

Le reset fait:
Si magic ok, appel 345340 et quitte
345340 (nouvelle sur AMS3):
 Si 5BBE.w != 0 && !IsClockOn
  5BB0.l = 0
  ClockOn

Si magic pas ok:
Clockoff(); ClockOn();
Appel OneSecondTimerSet(NewValue.l = 0, 0.w)
Fixe les formats + TimeZone
fixe magic et quitte

ClockOn est ralis par cette fonction d'initialisation plutt que
sparemment (sur AMS 2.09, il tait  la fin du 2me bsr de la srie
des bsr du reset [appel  la sous-fonction qui est le corps de
ClockOn]).

Tous les accs  OneSecondTimer sont maintenant remplacs par (cf plus
bas) :
3451D2: long OneSecondTimerGet (char *res)
345290 OneSecondTimerSet(NewValue.l, 0.w)




void OneSecondTimerSet (newValue.l, mmm.w)
---------------------

 345290
OneSecondTimer($5BB0) = newValue
Quitte si !IsClockOn
$710040.l = newValue
if (mmm.b < 16)
 tmp = mmm.b
else
 tmp = 0
$710044 = tmp
bclr #1,$710005F puis bset

long GetOneSecondTimer (char *res)
-----------------

 3451D2

if !IsClockOn
 *res = 0
 return OneSecondTimer ($5BB0)


 $46 est lu, $47 (avec 1(a0), etc... !), $48 et $49 et placs
cte  cte. Puis $45 est lu.
 (en fait les ports ne sont lus qu'une fois  chaque boucle)
  tmp = 0
  tmp2 = 0
  while ($46.l != tmp || $45.b != tmp2)
     tmp = $46.l
  *res = $45.b
  return $46.l

--------------------


Initialisation de ports par le 2me bsr de la srie du reset
============================================================
Code  222264.

A propos de $600000 (toute version d'AMS) et de la valeur initiale du
contraste (nouvelle valeur spciale pour Titanium).

($5B30 est l'quivalent du $5B98 sur V200 2.09, valeur du constraste)
(d1.b : $5D18, d0.b 5B30)
Si HW1
 $10 -> d0 #E maintenant !
 F -> d1
Si HW2
 20 -> d0
 1F -> d1
Si $5B19 != 0 ; toujours vrai sur HW1 ! cf 'reset' plus bas
  avant ------
   $A -> D0
  nouveau -----
  Si HARDWARE_PARM_BLOCK.hardwareID == 9 (Titanium)
   $D -> D0
  Sinon
   D0 /= 2
  Fin nouveau ------
Sinon
 #$80.b->$600000 (?)
$5B30 = d0.b (valeur du contraste)
OSContrastUp pour la fixer rellement.

Et dans OSContrastUp ou Dn :
Si $5B19 = 0
  Si nouvelle valeur contraste % 2 ? bset : bclr  #5,$600000

Et au tout dbut du reset :
Si pas HW1
  $5B19 = $FF
Sinon
  600018.w = $FFFF (~2.9V)
  $600000.b = $80
  wait
  $5B18.b = $1F ; contraste max (cf $60001D)
  btst #2,$600000
   seq d0 (clr si batt level is above)
  move.b #$FF,5B19
 ; puis d0 pas utilis !
  beq ContinueReset ; jamais vrai ! (aurait du tre avant l'instruction
                    ; prcdente ?)
  bclr #7,$600000
  bclr #4,$5B18 ;  contraste max - donc toujours fais sur HW1
                ;  -> $5B18=$F

TODO
Pas trs clair, toute info est la bienvenue.


Autres ports
============

$71004D
-------

USB: Searching for device... pour envoi  partir du var-link  34A1A8
La plupart des ROM Calls semblent fonctionner avec les anciens ports
i/o  $6000xx (LinkTxQueueActive, OSLinkReset, OSLinkClose, ...)
Regarder toutes les RC de link.h. (utilisation en mme temps que
5B35:1). Par exemple 349E58, 34A284, 34B868, et encore quelques
routines aprs ces adresses (search).
  et trap #4 : 347664, 347160
Envoi des donnes par bloc ? (il y a des memcpy dans trap #11 : $15)

$71005A
-------

A EV_getc.


==============================
Infos sur USB de Dan Englender
==============================

Horloge
-------

"bit 6, iy+3Fh controls whether the clock is on or off (regarding the
OS setting, not the hardware setting)."
$5F:0 semble tre l'quivalent ?

"To set the clock, set the values you want into ports 41h through 44h,
and then output 01h to port 40h, followed by 03h to port
40h. Outputting values directly to ports 45h through 48h has no
effect."
41h->44h = $40.l?
Mais ne ressemble pas trop (cf OneSecondTimerSet qui est plus
compliqu).

USB
---

<<The following ports seemed to be obviously related to the USB
because their values changed when I plugged in the cable: 49h, 4Ah,
4Ch, 4Dh, 4Fh, 54h, 57h, 5Bh, 80h, 81h, 87h, 89h, 8Bh, and A0h through
AFh.
Additionally, the following ports seemed related to USB because they
were accessed in what I think is link code: 8Eh, 8Fh, 90h, 91h, 92h,
93h, 94h, 98h, 9Ah.>>

Mme ports aux mmes adresses ! (encore un peu plus mme)
Mais il y a des ports de $22  $39 que Dan ne cite pas...


------------------------

---------------------------

TESTS
=====

SIDE, ID et BomberMaze68k semblent fonctionner (sans compter la
protection d'excution).


---------------------------

BUGS
====

Ils sont dus  de mauvais patches par patchanic. Pas vraiment le temps
de les corriger, et ils ne gnent pas trop pour l'instant.

Menu F5 du var-link compltement bugg.
Pareil pour Menu F6 ligne 1 de Home.
Dans catalog, au milieu des C : all rights reserved, etc... (~8
symboles pas bon). Et les commandes clrdraw, clrhome, etc. ont
disparues et ne rpondent pas dans l'home. (srement un patch de donnes
des commandes... TODO : voir ou ca se trouve).
Sendcalc variableexistantpas fait une link transmission error...
Pas d'horloge ? (car le bit sur $6000xx ne tiens pas ?)
Commande sur la clock dans home par reconnue : par exemple ClockOn

---

Boot : boucle bizarrement. + problme de check de battery d'aprs Samuel ?
port lu  2060E8 pose problme ?

trap 11 : 7 et $D ne fonctionnement pas. Seulement $D toujours excut
mme sans Flash Apps.

-------------------


=====
TODO
=====

Nouvelle combo != APPS+ON pour recevoir l'AMS via l'USB, comme sur
  84P? (apparemment non)
Changements au niveau de l'cran ? (la valeur initiale du contraste
  n'est plus la mme).
Comment envoyer via le port USB (ROM CALL sendcalc() passe par
l'ancien) ?
Bug du reset ne protgeant pas correctement la mmoire archive en
excution corrig ?
Mme stealth i/o ports ?
Protection du boot comme sur V200 ?
Chercher msg USB Device...
  +USB: Searching for device
  +USB: Device Not Supported
  +USB: Device Not Responding 
  et quand 'not supported'. Regarde AI4.
  Pourrait tre interessant de dtailler son protocole/fonctionnement
  pour dialogue avec un priphrique externe ?
Regarder ports io (boot + trap #11 + AMS)
Samuel : changement dans le fonctionnement des piles ?
Nouvelles Fonctions du trap #11, comprendre
Tenter un programme de diff d'AMS ?
Trouver une utilit pour les hooks des limites de RAM et ROM.
222300 : mais #$80,$600000 dans un cas alors que j89hw dit toujours 0
  (sur ancien AMS aussi). bug de Lionel ?
Automatiser le patch des mthodes des Flash Apps (cf partie patches).
Comprendre trap #11 : $15/$16
voir utilisations mdp / $5B35 ailleurs encore.
criture de 4 octets dans port clock possible, ou octet par octet
  ncessaire comme le fait l'AMS ?
Comprendre "Initialisation de ports par le 2me bsr"
Ports de $22  $39 que Dan ne cite pas, pas USB ?
Chercher ports $7100XX dans AMS, pas dj lists. 
AI3 : code
Routines autour de ClockOn, etc.
Ports Nouveaux, diffrents  $7000xx ? Comparer toutes les ini des
  anciens ports par le reset.

Demander Samuel / Buvhanesh
===========================

Qui a-t-il  la place du ghost space de la RAM ?


End Of File
